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(54) Pictographic electronic program guide 

(57) A system and method for displaying a picto- 
graphic program guide (PPG) to assist users in deter- 
mining and selecting television viewing options and 
related services is described. The PPG is constructed 
at receiver stations based on data periodically received 
via a Direct-to-Home (DTH) satellite communication 
system. Preferably, the data decoder of the receiver sta- 
tion is a personal computer or a device having similar 
processing power. The PPG includes still pictures, live 
video broadcasts, still graphics, moving graphics, web 
pages, links and "buttons" that are utilized by the viewer 
to perform a variety of operations, including determining 
program availability, selecting programming or services, 
and launching to related information, programming or 



services. The PPG layout and organization is defined by 
one or more templates, and the basic instructions for 
building the templates are broadcast to the receiver sta- 
tions. The PPG, according to the present invention, is 
constructed from both real time broadcast data 
("streaming" data) and periodically downloaded and 
stored data ("file" data). By broadcasting the template 
information, along with instructions or linking-data on 
how to fill in the template using the streaming and file 
data, the broadcaster can easily change the PPG pres- 
entation format by changing the broadcast template 
information. 
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Description 

BACKGROUND OF THE INVENTION 

(a) Field of the Invention 

[0001] The present invention relates in general to 
entertainment broadcast systems that transmit and 
receive a wide variety of video, audio, software and 
other types of data. More particularly, it relates to a 
multi-channel broadcast system that transmits a 
video/text/graphic-based program guide data stream 
that is used at viewer stations to generate a user inter- 
face that facilitates a user's selection of various pro- 
grams and services. 

(b) Description of Related Art 

[0002] The use of electronic communications media 
to provide access to large amounts of video, audio, tex- 
tual and data information is becoming more frequent. 
For example, the public switched telephone network 
(PSTN) is routinely used to transmit low speed digital 
data to and from personal computers. Cable television 
infrastructure is used to carry, via coaxial cable, analog 
or digital cable television signals, and may also be used 
to provide high speed Internet connections. In general, 
cable television infrastructures include many head end 
or transmission stations that receive programming from 
a variety of sources, then distribute the programming to 
local subscribers via a coaxial cable network. Large 
DirecMo-Home (DTH) satellite communications sys- 
tems transmit directly to viewers over one hundred fifty 
audio and video channels, along with very high speed 
data. DTH systems typically include a transmission sta- 
tion that transmits audio, video and data to subscriber 
stations, via satellite. 

[0003] One particularly advantageous DTH satellite 
system is the digital satellite television distribution sys- 
tem utilized by the DIRECTV® broadcast service. This 
system transports digital data, digital video and digital 
audio to a viewer's home via high-powered Ku-band sat- 
ellites. The various program providers send program- 
ming material to transmission stations. If the 
programming is received in analog form, it is converted 
to digital. The transmission stations compress the digital 
video/audio programming (if needed), encrypt the video 
and/or audio, and format the information into data 
"packets" that are multiplexed with other data (e.g., 
electronic program guide data) into a plurality of bit- 
streams, which include identifying headers. Each pack- 
etized bitstream is modulated on a carrier and 
transmitted to a satellite, where it is relayed back to 
earth and received and decoded by the viewer's 
receiver station. The receiver station includes a satellite 
antenna and an integrated receiver/decoder (IRD). The 
IRD may be connected to appropriate output devices, 
typically including a video display 



[0004] In general, DTH satellite(s) broadcast on 
several frequencies from multiple transponders at differ- 
ing polarizations (e.g., left and right hand circular polar- 
ization), and each transponder bitstream includes the 

5 video and audio data packets (in a compressed format) 
for several different programs (or "viewer channels"). 
For example, transponder one may broadcast the digital 
video and audio data packets for ESPN, TNT, AMC, 
A&E, E!, STARZ and USA, in a statistically multiplexed 

w fashion. Satellites or other distribution systems which 
require separate input processing (e.g., satellites at two 
separated locations requiring different antennas) may 
also be used. Accordingly, in order to receive a desired 
viewer channel, the receiver station must know the 

is transponder frequency and the polarization at which the 
desired signal information is being broadcast by the sat- 
ellite, along with the identifying header information for 
those data packets on that transponder that relate to the 
desired program to permit its isolation from the multi- 

20 plexed bitstream. 

[0005] Each satellite transponder broadcasts a pro- 
gram guide data stream, which typically includes not 
only broadcast schedule data, but also the aforemen- 
tioned information that the receiver station needs in 

25 order to tune to a particular channel The program guide 
data stream is broadcast on all satellite transponders so 
that channel selection information is always available to 
the IRD regardless of the channel to which the IRD is 
tuned. 

30 [0006] The data packets are distinguished from one 
another by their header information, which is referred to 
as the packet's "service channel ID" (SCID). For exam- 
ple, if a viewer instructs the IRD to display ESPN, the 
IRD, via the tuning information in the program guide 

35 data stream, determines the transponder frequency and 
polarization at which the ESPN programming is broad- 
cast, along with the SCIDs of the data packets that are 
needed to generate and display the video, audio, and 
data content of the ESPN program. 

40 [0007] The scheduling data in the program guide 
data packets also provide channel and program- 
attribute information that is used by the IRD to construct 
and output as a viewable display (which may be a full or 
a partial screen) a text-based listing of programming 

45 channels, times, titles, descriptions, ratings, etc. In 
operation, a program guide display is typically pre- 
sented as a grid having channels listed along the left, 
times across the top, and program titles shown within 
the grid squares. Users can scroll through the grid, 

so either up and down (by channel) or to the left and right 
(by time). Channels can be selected by inputting the 
channel number directly using the number keys on a 
user's remote control, or channels may be selected from 
the program guide display by highlighting and selecting 

55 a currently broadcast program that is listed in the grid. In 
either case, the IRD tunes to the chosen channel by 
accessing the channel's transponder (frequency), polar- 
ization, and SCID information denoted by the program 
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guide data stream. 

[0008] An extension of known IRD equipment is a 
PC-based system that allows users to receive, directly 
into their PC s, the same digital video, audio, and related 
information signals received in conventional DTH sys- 
tems. The receiver station in this PC-based system 
includes a local satellite receiver dish similar to that of a 
conventional IRD system, but the IRD functions are 
implemented within the PC architecture through the use 
of one or more circuit boards that are inserted into the 
PC. The decoded outputs from these boards are dis- 
played on the PC's monitor, or may be output to a con- 
ventional video display (e.g., a television set) and/or 
other mass storage medium such as magnetic tape, 
digital video disk (DVD), optical or magnetic disk, video 
recorder (VCR), etc. Because the receiver station 
includes a personal computer, a large number of addi- 
tional data and software-related services can also be 
downloaded directly to the PC. thereby offering a variety 
of services, including broadcast programming, pay-per- 
view events, audio programming, data services, web- 
casting, software downloads and other data or soft- 
ware-related services. 

[0009] One example of a known electronic program 
guide is described in U.S. Patent No 5,633,683, entitled 
"Arrangement And Method For Transmitting And 
Receiving Mosaic Video Signals Including Sub-Pictures 
For Easy Selection Of A Program To Be Viewed ", issued 
May 27, 1997 to Rosengren et al. The Rosengren et al. 
patent discloses a video-based electronic program 
guide, wherein the available programs are conveyed to 
the viewer by displaying a so-called "mosaic" made up 
at the broadcast site of the live video from each of the 
transmitted channels. The mosaic is essentially a single 
image divided into a plurality of areas, wherein each 
area displays the live video of one of the available pro- 
grams. A user selects a channel by moving a cursor 
over the video area displaying the desired program- 
ming, then pressing a select button on either the televi- 
sion or the users remote control. The selected live 
video image is then tuned and displayed. In an alterna- 
tive embodiment, the live video in any area of the 
mosaic is automatically replaced with a still picture of 
the program if it is determined that the live broadcast is 
currently a commercial instead of the actual program. 
[0010] Another video-based electronic program 
guide is disclosed in a European patent application enti- 
tled "Television Signal Transmission And Reception 
System With Multi-Screen Display For Tuning Opera- 
tion," published May 25. 1994 and bearing publication 
no. 0 598 576 A2 (filed by Toshiba). The Toshiba EPO 
application, like Rosengren et al., discloses a video- 
based electronic program guide wherein the available 
programs are conveyed to the viewer by displaying a so- 
called "multi-screen" display made up at the broadcast 
site of live video from each of the transmitted channels. 
The multi-screen is essentially a single screen divided 
into a plurality of areas, wherein each area displays the 



live video of one of the available programs. A user 
selects a channel by moving a cursor over the video 
area corresponding to the desired programming, then 
pressing a select button on either the television or the 

5 user s remote control. The selected live video image is 
then tuned and displayed in the full screen. In an alter- 
native embodiment, the video-based program guide is 
applied to a two-way CATV system, and the viewer's ini- 
tial request for program guide information is sent back to 

io the broadcast center which transmits to the viewer a text 
listing of categories into which the available programs 
and channels have been divided. The viewer selects a 
category, and this category selection is transmitted back 
to the broadcast center which may then transmit 

15 another listing of subcategories related to the chosen 
category. The viewer continues to select subcategories 
until no further subcategories are available, at which 
time the broadcast center transmits a multi-image 
screen containing only the video images from those pro- 

20 grams that fall in the selected category and subcatego- 
ries. 

[0011] U.S. Patent No. 5,523,796, entitled "Video 
Clip Program Guide" and issued to Marshall et al. on 
June 4, 1996, discloses a text-based program guide laid 

25 out in a grid. Video clips from certain programs are 
stored at the viewer's station, and the programs that 
have video clips available are shown in the grid program 
guide with an icon next to the program's title. A viewer 
who desires to see a video clip selects the icon associ- 

30 ated with the program, and the viewer station runs the 
video clip in a portion of the screen. The rest of the 
screen displays text information such as the program's 
title, channel, start and end times, content description, 
etc. Other program guide and/or multi-image systems 

35 are disclosed in U.S. Patent Nos. 5,231 ,493; 5,422,674; 
5,398,074; 5,430,486; 5,434,624; 5,442,398; 
5,452,012; and 5,047,867. 

[0012] While known program guides have advan- 
tages, there is still room for improvement, particularly 

40 when considering the large number of data, software, 
video, audio, pay-per-view and other programming serv- 
ices available through present and future DTH satellite 
broadcast services. For example, the viewable display 
generated from electronic program guide data tends to 

45 be presented primarily, as text laid out in a grid. The 
processing power of currently available IRD's, while 
appropriate for current DTH programming services, 
inherently limits how the program guide can be dis- 
played, how much information can be incorporated into 

so the guide, and how quickly and efficiently a user can 
move through the guide. These program guides are 
therefore essentially limited to conveying program avail- 
ability and tuning information, and do not have the 
organization and flexibility to effectively support other 

55 services such as software downloads, webpage links 
and downloads, data services, and other functions. 
[0013] Accordingly, for broadcast systems having a 
large number of services that deliver a large amount of 
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data to relatively sophisticated receiver stations (e.g., a 
PC), there is a need for a broadcast electronic program 
guide and an associated viewable display format and 
content that significantly enhances how the program 
guide can be displayed, how much information can be 
incorporated into the guide, and how quickly and effi- 
ciently the user can move through the guide. 

SUMMARY OF THE INVENTION 

[0014] The present invention provides a method 
and apparatus for efficiently and effectively transmitting, 
receiving, organizing and selecting transmitted data. 
The method and apparatus of the present invention is 
preferably embodied in a user interface and related data 
protocols and procedures. The user interface may be 
implemented in the context of a wireless distribution 
system for securely, reliably and inexpensively distribut- 
ing video, audio, data service, software and other serv- 
ices to geographically remote receiver stations. The 
wireless distribution system is preferably a DTH digital 
satellite television distribution system, though other sys- 
tems (e.g., terrestrial wire, cable, or wireless broadcast) 
may also be used in other embodiments. A typical DTH 
digital broadcast system includes a transmission sta- 
tion, a satellite relay, and a receiver station. At the trans- 
mission station, video and audio programming signals 
are digitized in known manners, multiplexed with other 
data signals (such as the data needed to construct a 
program guide display according to the present inven- 
tion), compressed (if required), encoded, mated with 
error correction codes, modulated on carriers, and 
uplinked to a geosynchronous satellite. The satellite 
receives the uplinked signals and rebroadcasts them 
over a footprint that preferably covers a predetermined 
geographical area, for example, the continental United 
States. Receiver stations, which are typically located at 
the user s home or business, receive the satellite sig- 
nals. The receiver stations each include an antenna, 
which preferably is in the form of a satellite dish, along 
with an integrated receiver/decoder (IRD). The antenna 
feeds the received satellite signal to the IRD unit which 
recovers the originally transmitted digital video, audio, 
and data. Other receiver station equipment (e.g.. cable 
decoder units) may be used with other distribution sys- 
tems in other embodiments, as is well known in the art. 
[001 5] The present invention is particularly applica- 
ble to a receiver station having sufficient processing 
power to process and generate a program guide display 
and associated features that goes beyond conventional 
video/text/grid program guides. The processing power 
may be incorporated directly into the IRD. for example, 
by adding a more powerful microprocessor, more mem- 
ory, and associated software to the conventional IRD 
circuitry. Alternatively, the receiver station IRD may be 
replaced with a PC having circuit cards that perform the 
IRD functions. A PC-based system significantly 
increases the receiver station's processing power, along 



with the number of services (e.g., data services and 
software) the receiver station can receive and use. 
Accordingly, the features of the present invention are 
most advantageously utilized by a PC-based (or compa- 

5 rable) receiver station. 

[0016] A PC-based receiver station suitable for use 
with the present invention includes an antenna, which 
preferably is in the form of a satellite dish, along with a 
PC which, like the above-described IRD, recovers the 

io originally transmitted digital video, audio, and data. The 
digital broadcast data received from the satellite dish is 
coupled directly into a transport circuit board within the 
PC. The PC's transport circuit board also performs ini- 
tial circuit functions on the signal coupled in from the 

is antenna, including tuning, demodulation, and forward 
error correction (FEC). The transport circuit board 
within the PC also performs similar functions to that of 
the IRD's transport circuit, including channel de-multi- 
plexing, decryption and access determination. The 

20 received digital broadcast data is sent from the trans- 
port circuit to video/audio decoder circuits, which may 
be on the same or separate circuit board. The 
video/audio decoder circuit board decompresses and/or 
decodes the received compressed broadcast signal. 

25 [001 7] In one embodiment of the present invention, 
the transmission station transmits to the receiver sta- 
tions program selection data/information that is used at 
each receiver station to construct an electronic program 
guide and associated display format and content (i.e., a 

30 user interface) that, in contrast to known video-based 
and/or text/video/icon-based electronic program guides, 
significantly enhances how the program guide can be 
displayed, how much information can be incorporated 
into the guide, and how quickly and efficiently a user can 

35 move through the guide. The viewable display format, 
according to the present invention, incorporates moving 
picture video, still pictures, text, links to external data 
sources, graphics and other features that facilitate the 
selection of various programs and services. 

40 [0018] The transmission station (e.g., uplink facility) 
transmits to the receiver stations the pictographic pro- 
gram guide (PPG) data/information needed at each 
receiver station to construct the PPG display. The 
broadcast PPG data can be divided into three catego- 

45 ries. The first is real time conventional text/grid-based 
program guide data. The conventional guide data 
includes schedule and program attribute information, 
along with information that the receiver station needs in 
order to tune to a particular channel. In a typical DTH 

so system, the conventional program guide data stream is 
broadcast on all satellite transponders so that channel 
selection information is always available to the receiver 
station regardless of what channel the receiver station 
is tuned to. In general, tuning the receiver station to a 

55 particular channel requires knowledge of at least the 
satellite transponder on which the channel is broadcast, 
along with polarization information and information 
identifying which data packets on that transponder cor- 
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respond to the channel of interest. 
[001 9] The second category of broadcast PPG data 
may be referred to as "streaming" data, which is real 
time PPG data transmissions other than the conven- 
tional guide data. Streaming data can cover a variety of 
data types including, for example, "ticker" data (stocks, 
sports scores, etc.) and PPG "template" data (i.e., 
instructions to the receiver station on how to construct 
and lay out the display of the PPG). 
[0020] The third category of PPG data may be 
referred to as PPG "file" data. PPG file data is periodi- 
cally (e.g., once a day at 2:00 a.m.) downloaded to the 
receiver station and stored in memory. File data 
includes various information that is related to the PPG 
but is sufficiently static so that it does not need to be 
sent in real time. For example, the transmitted file data 
may be still pictures related to various channels and/or 
services and used to construct a portion of the PPG dis- 
play, moving video clips related to the various channels 
and/or services and used to construct a portion of the 
PPG display, Web pages related to the various channels 
and/or services, and linking information that identifies 
and provides access to related information. The links 
may connect to either internal resources (e.g., cached 
Web pages) or to external resources (e.g., a URL to an 
external Web site). If the DTH broadcast system 
includes a software feature known as "webcasting." the 
file data may include a data catalog indicating the web- 
casting broadcast schedule. In general, webcasting 
involves accessing at the uplink a variety of web sites 
from the world-wide web, and broadcasting those web 
sites to the subscriber stations at selected times. View- 
ers wishing to receive a particular website would access 
the data catalog to determine the broadcast time and 
channel, and tune their receiver to that channel at the 
designated time. 

[0021] Several examples of a particular PPG tem- 
plate embodying the present invention are shown in 
FIGS. 2-5. As shown in FIG 2, for example, the lay- 
out/content of the illustrated PPG screen 220 includes 
five major segments. The first segment is an active 
video segment 222 that displays the video/service 
channel to which the receiver is currently tuned. The 
second segment is a category segment 226. All of the 
available channels are divided into categories such as 
sports, movies, news, data services, etc., and these 
available categories are listed in the category segment 
226. Each category has its own template instructions 
that may be different from or the same as the templates 
in other categories. If the number of programs/services 
in a given category is more than fits on a single tem- 
plate, additional templates in the form of additional tem- 
plate "pages" are created for that category. Selecting a 
particular category selects the template page(s) that 
present the programming/service that fall under that 
category. A third segment, the "page" segment 232, 
allows the user to move around the various pages of a 
template by selecting the page segment 232. 



[0022] The fourth segment is a video/picture seg- 
ment 228 shown as a matrix of six 3:4 aspect ratio areas 
each representing a programming channel or service 
channel that may be accessed by the receiver station. 

5 Selecting one of the videofcicture areas selects the 
channel associated therewith. The areas are linked to 
the program guide tuning information in the same way 
that the display text-based grids and channel numbers 
are linked to the tuning information. Accordingly, select- 

10 ing the video/picture area that represents ESPN, links 
the receiver to the program guide tuning information 
(transponder and SCID) needed to acquire the program 
currently being broadcast on ESPN. An additional fea- 
ture is an information area that can pop up (overlaying a 

75 portion of the current display) whenever a cursor moves 
over a given video/picture area. The information area 
could provide any desired information about the pro- 
gram, for example, the title, program description, pro- 
gram duration, program rating, etc. 

20 [0023] The fifth segment is the "link" segment, 
which can be found in various areas on a given screen. 
The "links" include graphical interface "buttons" and 
other graphic symbols for selecting certain features 
and/or launching the PPG into various states are pro- 

25 vided for the active video segment 222, the video/pic- 
ture segment 228 and special auxiliary areas 234, 
located at the bottom of a given template page. Each 
link, like the video/picture areas, represents a related 
channel, service or other information that can be 

30 accessed from the PPG. Selecting a link may initiate a 
series of local interactions involving primarily the 
receiver station hardware, or the link may initiate exter- 
nal interactions with other hardware/systems such as 
the Internet. For example, "web" links allow the viewer 

35 to either "pull-up" a related web page stored at the 
receiver station or launch to external equipment/sys- 
tems to access the web-page information, grid-guide 
links allow the viewer to move from the PPG to the grid- 
guide, "preview" links allow the user to select and run 

40 video clips of the program in its video/picture area, "soft- 
ware" links allow users to download related software 
(e.g., computer games, applications software or web 
originated software), "view" links make a given picture 
area active, "full" links put the associated video/picture 

45 area in the full screen, "record" links use the broadcast 
time and channel information associated with a program 
to control a video recorder to record the program at its 
broadcast time, "buy" links allow users to purchase pay- 
per-view programming or services via conventional 

so impulse-pay-per-view purchase screens, and data-cata- 
log links take the user to the webcaster broadcasting 
schedule for the system. 

[0024] The PPG, according to the present inven- 
tion, is constructed from both real time broadcast data 
55 ("stream" data) and periodically downloaded and stored 
data (*1ile" data). By broadcasting the template informa- 
tion, along with instructions on how to fill in the template 
using the streaming and file data, the broadcaster can 
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easily change the PPG presentation format by changing 
the broadcast template information. In operation, a user 
selects a category, and the channels that fall within the 
selected category are displayed according to a particu- 
lar template format. The templates are a particular lay- 
out and configuration of graphics, still pictures, moving 
pictures and text representing the content of the chan- 
nel and associated information and/or services. Select- 
ing a portion of the PPG display selects the 
programming, channel, service or related data or oper- 
ation represented by that portion of the display. Select- 
ing a portion of the display can involve primarily local 
operations, or can launch to external devices/systems 
such as the Internet. Additionally,. by limiting the number 
of video/picture segments that can be active at any time, 
the present invention avoids the confusion associated 
with known picture-based program guides that have 
from sixteen to twenty-five separate active video areas 
in a given screen of the guide. Thus, the program guide 
of the present invention provides an intuitive system and 
method for browsing and selecting television program- 
ming and a wide variety of broadcast services. 
[0025] The invention itself, together with further 
objects and attendant advantages, will best be under- 
stood by reference to the following detailed description, 
taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] 

FIG. 1 is a diagram of a direct-to-home (DTH) trans- 
mission and reception system capable of broad- 
casting and utilizing data streams embodying 
aspects of the present invention; 
FIG. 2 illustrates an example of one "page" of a pic- 
tographic program guide embodying aspects of the 
present invention; 

FIG. 3 illustrates an example of another "page" of a 
pictographic program guide embodying aspects of 
the present invention; 

FIG. 4 illustrates an example of another "page" of a 
pictographic program guide embodying aspects of 
the present invention; 

FIG. 5 illustrates an example of still another "page" 
of a pictographic program guide embodying 
aspects of the present invention; 
FIG. 6 is a diagram of selected hardware process- 
ing components of the receiver station shown in 
FIG. 1 ; 

FIG. 7 is a block diagram illustrating one possible 
system architecture within which aspects of the 
present invention may be used; 
FIG. 8 is a diagram illustrating a type of transport 
data packet that may be transmitted via the system 
shown in FIG. 1 ; 

FIG. 9 is a block diagram illustrating a preferred 
data flow through a protocol stack for use with the 



present invention; 

FIG. 10 is a block diagram illustrating a preferred 
method of processing a data packet for use with the 
above- referenced protocol stack; 
5 FIG. 1 1 is a representation of a BFDP header; 

FIG. 12 is a representation of a UDP header; 
FIG. 13 is a diagram of a version 4 IP packet 
header; 

FIGS. 14A - 14D are block diagrams representing 
w MPT packets; 

FIGS. ISA and 15B are diagrams representing a 
BARP header and a BARP address record, respec- 
tively; and 

FIGS. 16A - 16D are sample SDP + records for var- 
15 ious information services that may be used with the 
present invention. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

20 

[0027] To fadlitate review and understanding of the 
invention and the preferred embodiments, the present 
disclosure has been organized in accordance with the 
headings and sub-headings shown below. 

25 

I. System Overview 

II Pictographic Program Guide (PPG) 

III. Receiver Station Generally 

IV. Receiver Station Architecture 
30 V. Data Packet 

VI. AudioA/ideo Processing 

VII. Data Processing 

A. Protocol Stack/Broadcast File Download 
35 Protocol (BFDP) 

B. Broadcast Address Resolution Protocol 
(BARP) 

C. SDP+ Records 

D. Webcast 

40 

VIII. Conclusion 
I. System Overview 

45 [0028] By the way of example only, the method and 
apparatus of the present invention is disclosed in con- 
nection with a system that broadcasts, via satellite, 
video programming, data services and multimedia data 
(e.g., webpages). It should be understood, however, 

so that any system requiring intuitive interactive program 
and/or service selection may alternatively employ the 
techniques shown herein. Such systems might include 
other broadcast communications techniques not tradi- 
tionally associated with video programming or the Inter- 

55 net. For example, paging or cellular systems delivering 
news or other information could benefit from certain 
aspects of the method and apparatus of the present 
invention. 
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[0029] Generally, however, the techniques of the 
present invention are best used by broadcast video and 
data systems having a large number of available pro- 
grams, data and services, thereby benefitting from the 
simplification of programming organization and selec- 5 
tion provided by the present invention. A preferred 
broadcasting system is the satellite-based system uti- 
lized by the DIRECTV® broadcast service. Such 
embodiments of the present invention employ a satellite 
receiving antenna to acquire real-time video broadcasts w 
and periodic data broadcasts used to construct a pro- 
gram guide display. It should be understood, however, 
that many other delivery systems are readily applicable 
to alternate embodiments of the present invention. Such 
systems include wired or cable distribution systems, 75 
UHF/VHF radio frequency systems or other terrestrial 
broadcast systems (e.g., MMDS, LMDS, etc.), and fiber 
optic networks. 

[0030] FIG. 1 illustrates a typical Direct-to- Home 
(DTH) PC-based satellite communication system 100 20 
capable of utilizing the present invention. The system 
100 includes a transmission station 102, a satellite/relay 
104, and a plurality of receiver stations, one of which is 
shown at reference numeral 106. Wireless communica- 
tions are provided between the transmission station 25 
1 02, the satellite/relay 104. and the receiver station 106. 
The transmission station 102 includes programming 
sources 108. a control data source 1 10, a data service 
source 112, one or more program guide data sources 
1 1 4, a video/audio/data encoding system 1 1 6, an uplink 30 
frequency converter 118, and an uplink antenna 120. 
The data service source 112 receives data service infor- 
mation and webpages made up of text files, graphics, 
audio, video, software, etc. from a network 122 (e.g., the 
Internet, a LAN or a WAN). The satellite/relay 104 is 35 
preferably at least one geosynchronous or geo-station- 
ary satellite. The receiver station 106 shown in FIG. 1 
includes a reception antenna 124 connected to a low- 
noise-block (LNB) 126, and an integrated 
receiver/decoder (IRD) embodied in a personal compu- 40 
ter (PC) 128 having a monitor 130 and a computing unit 
132. Other devices, such as another video display 
device (e.g., television) 134 and a video recorder 136 
(eg. VHS, DVHS, DVD, etc.), may also be supported, if 
desired. 45 
[0031] In operation, the programming sources 108 
receive video and audio programming from a number of 
sources, including satellites, terrestrial fiber optics, 
cable, or tape. The received programming signals, 
along with data signals from the control data source so 
110. the data service source 112. and the program 
guide data sources 114. are sent to the 
video/audio/data encoding system 1 1 6 where they are 
digitally encoded into information data streams that are 
multiplexed into a packetized data stream or bitstream 55 
using a number of conventional algorithms. Each data 
packet within the packetized data stream includes a 
header that identifies the contents of the data packet 



and a service channel identifier (SCID) that identifies 
the data packet. In a conventional manner, the encoded 
bitstream is modulated and sent through the uplink fre- 
quency convener 118, which converts the modulated 
encoded bitstream to a frequency band suitable for 
reception by the satellite/relay 104. The modulated, 
encoded bitstream is then routed from the uplink fre- 
quency converter 1 1 8 to the uplink antenna 1 20 where 
it is broadcast toward the satellite/relay 104. The satel- 
lite/relay 104 receives the modulated, encoded bit- 
stream and re-broadcasts it downward toward an area 
on earth that includes the receiver station 106. The 
reception antenna 124 of the receiver station 106 
receives the signal, which is typically shifted from, for 
example, the Ku-band signal down to, for example, an L- 
band signal by the LNB 126. The LNB output is then 
provided to the PC 128, the television 134 and/or the 
video recorder 136. As noted above, the PC 128 
includes conventional IRD functions (provided, for 
example, by plug-in circuit cards (boards). Thus, when 
the user commands the PC 128 to tune to a particular 
program, the PC 128 associates the users program 
selection with a transponder and SCID number and 
tunes the IRD to receive data packets from the appropri- 
ate transponder and to select data packets having the 
appropriate SCID number from the multi-program data 
stream. 

[0032] Although not necessary for proper operation 
of the disclosed system, the receiver station 106 may 
optionally incorporate a connection (e.g., Ethernet cir- 
cuit or modem) to the network 122 for transmitting 
requests and other data back to the transmission station 
102 or other location (or a device managing the trans- 
mission station 102 and overall flow of data in the sys- 
tem 100) and for communicating with network devices 
138 (e.g., websites) that may be on the network 122. 
[0033] In general, the software executed by the PC 
128 includes many conventional PC operations used to 
generate a pictographic program guide (PPG) having a 
mouse-controlled cursor or the like, windows, dialogue 
boxes, buttons, and other such features that facilitate 
user selection of various options. The PPG of the 
present invention is assembled using two basic types of 
external data: (1) real-time broadcast data (e.g. stream- 
ing data), and (2) file data (i.e., data that is periodically 
downloaded and stored). Real-time data includes con- 
ventional program guide data (e.g.; program attribute 
data, tuning data, etc.), ticker data (e.g., stocks, sports 
scores, etc.), some SDP+ records, and announcements 
(e.g., updates to the webcast data catalog, etc.). File 
data includes information that is updated periodically 
such as still pictures, moving video clips, webpages, 
data catalog (webcast schedule), links to other internal 
or external sources of information, and various discrete 
software downloads. The PPG of the present invention 
organizes and simplifies the presentation of real-time 
broadcast data and file data by providing, inter alia, a 
plurality of pages, wherein each page has a display with 
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several distinct segments. For example, a given page 
type may simultaneously provide still pictures, moving 
videos, text, graphics, audio, and data within separate 
segments. 

[0034] The PPG of the present invention requires 
the presence of appropriate data at the receiver station 
106. One method of generating appropriate data and 
reliably transferring it to the receiver station 106 using a 
hardware configuration as shown in FIG. 1, is disclosed 
in detail below in section VII of this disclosure. Gener- 
ally, the method set forth in section VII includes a data 
transfer technique, referred to herein as broadcast file 
download protocol (BFDP), that operates in a one-way 
broadcast communication link. BFDP is the subject of a 
co-pending commonly assigned application entitled 
filed on and bear- 
ing serial no. / . BFDP breaks 

large data files for transmission into numerous small 
data packets, which are labeled in a sequential manner 
at the transmission station 102 and broadcast to the 
receiver station 106. BFDP facilitates the assembly of 
the labeled data packets back into the large data file and 
enables identification of missing or corrupt data packets 
at the receiver station 106. Any missing or corrupt data 
packets at the receiver station 106 can be obtained and 
inserted into their correct locations in the large data file 
during subsequent transmissions of the large data file. 
Thus, if during the transmission of a large data file a 
number of its data packets are missing or corrupt, only 
the missing or corrupt data packets need be reacquired 
during a subsequent re-broadcast of the large data file, 
and not the entire large data file. 
[0035] A method for resolving an Internet protocol 
(IP) address into a physical address is also described in 
section VII of this disclosure. This method is referred to 
herein as a broadcast address resolution protocol 
(BARP). BARP is the subject of a co-pending commonly 

assigned application entitled , 

filed on and bearing serial no. 

/ BARP is necessary because 

all file data (for example a large file transferred using 
BFDP, as discussed above) transferred to the receiver 
station 106 are identified by IP addresses and, as previ- 
ously noted, the receiver station 106 requires a trans- 
ponder and SCID to tune to receive the broadcast file 
data. Accordingly, BARP allows the receiver station 106 
to rapidly resolve an IP address for a desired program or 
service into a transponder and SCID. 
[0036] To inform the user of when and on what IP 
address the large file mentioned above will be broad- 
cast, session description protocol plus (SDP+) records 
are periodically broadcast by the transmission station 
102. SDP + records are the subject of a co-pending 
commonly assigned application entitled 
filed on and bear- 
ing serial no. / . SDP + records 

are processed by the receiver station 106 to produce a 
schedule of all data service information that will be 



broadcast by the transmission station 102. Additionally, 
the SDP + records are used by the PC 1 28 to build PPG 
pages using selected information resident within the PC 
system (e.g.. a basic page template) and selected 

5 dynamic data that is received from the satellite or an 
Internet connection. When the user launches the inter- 
face into another state or page, the PPG builds the des- 
tination page as instructed by the SDP + records and 
displays it on the user s PC system monitor 130. More 

w details about the SDP + records are provided in Section 
I of this disclosure in connection with the descriptions of 
FIGS. 16A-16D. 

II. Pictoaraphic Program Guide (PPG) 

15 

[0037] Several examples of a particular PPG tem- 
plate embodying aspects of the present invention are 
shown in FIGS. 2-5. As shown in FIG. 2, for example, 
the layout/content of the illustrated PPG page 220 

20 includes five major segments. The first segment is an 
active video segment 222 that displays the video/serv- 
ice channel to which the receiver is currently tuned. As 
shown in FIG. 2, a plurality of graphic buttons or links 
224 may be displayed adjacent to the active video 

25 image 222. These graphic buttons or links 224, when 
selected by the user, launch the PPG into one of a plu- 
rality of corresponding states that provide additional 
services or data associated with the active video image 
222. For example, selecting a "Grid" button transitions 

30 the active video/audio area 222 to the program grid- 
guide. Selecting a "Full" button may zoom the active 
video segment 222 to occupy a substantial portion of 
the display. Selecting a ZWeb" button could replace the 
video/picture segment 222 with a web page related to 

35 the currently tuned channel. For example, the "web" but- 
ton could bring up on an available area of the template 
a list of available web pages. The list of available web 
pages could replace the list of categories in a category 
area 226 that is discussed in more detail below. Also, as 

40 discussed in more detail below, selection of the "Web" 
button could invoke the retrieval of webpage information 
that is locally cached at the PC 128 or may, alternatively, 
invoke the PC 128 to access various websites 138 via 
the Internet connection 122 to download and display 

45 webpage information as needed. 

[0038] The second segment of the template 220 is 
the category segment 226. All available channels are 
classified into topics and displayed in the category seg- 
ment 226 as a list of categories that includes, but is not 

50 limited to, sports, movies, family, travel, favorites, news, 
data services, category related web pages, etc. Topic 
classifications could be directed by the broadcaster, by 
the user, or a combination thereof. For example, a user 
may create a 'Favorites' category and fill it by dragging 

55 a video area from a video/picture segment 228 to the 
category list 226. In other embodiments, a favorites cat- 
egory is automatically constructed via software resident 
in the PC 128 that observes the user's viewing habits. 



8 



BNSDOCID: <EP 1024661 A2J_> 



15 



EP 1 024 661 A2 



16 



[0039] The user selects a category by positioning a 
cursor using a selection device such as a mouse, keys, 
or remote control to highlight the desired category for 
display. The currently selected category is displayed in 
an area 230 of the page 220. Each category has its own 5 
template instructions that may be different from or the 
same as the templates in other categories. Thus, the 
layout, graphics, and other content of the various tem- 
plates can be optimized for the subject matter of each 
category. For example, the template for the "News" cat- 70 
egory could include a late breaking news banner in a 
portion of the display, whereas the template for the 
"Shopping" category could include a promotional ban- 
ner advertising/featuring various products and services. 
[0040] If the number of programs/services in a 15 
given category is more than fits on a single page addi- 
tional pages are created for that category. Selecting a 
particular category selects the template page(s) that 
present the programming/service that fall under that 
category. A third segment, the "page" segment 232, 20 
allows the user to sequence through the various pages 
associated with a selected category template. The user 
may, for example, select a right facing arrow to advance 
through the associated pages and a left facing arrow to 
return to previous pages. A second page associated 25 
with the page shown in FIG. 1 is illustrated, for example, 
in FIG. 3. 

[0041 ] The fourth segment is the video/picture seg- 
ment 228 that preferably includes a matrix of six 3:4 
aspect ratio areas each representing a programming 30 
channel or service channel, associated with the cur- 
rently selected category, that may be accessed by the 
receiver station 106. Each video area could include still 
pictures, still graphics, moving graphics, live broad- 
casts, text, or a combination thereof representing the 35 
content of the program currently being broadcast on 
that channel, or for some program that will be broadcast 
on that channel in the future. 

[0042] Delivery of the video/picture area may be 
accomplished via the live video broadcast, such as by 40 
freezing a frame or displaying live action or periodically 
sampled video. However, in preferred embodiments, the 
pictogram representing the program is selected by the 
program provider, broadcaster, 01 others to be a pre- 
ferred, symbol, graphic, picture or other pictogram illus- 45 
trative of the program content. In these embodiments, 
the pictogram data may be broadcast independently of 
the program content (e.g., well in advance for guides 
showing upcoming programs) via broadcast data, 
retrieved data, or a combination thereof. One or more of so 
the video areas can be made "active" (i.e.. the live 
broadcast) according to user's desires and the decod- 
ing capabilities of the user s video/audio decoder hard- 
ware/software. Accordingly, the user can have as many 
active video areas as desired. 55 
[0043] Selecting one of the video/picture areas 
selects the channel associated therewith and displays it 
in the active video segment 222. The video/picture 



areas are linked to the conventional program guide tun- 
ing information in the same way that known text-based 
program grids and channel numbers are linked to the 
tuning information. Accordingly, selecting the video/pic- 
ture area that represents ESPN, for example, links the 
receiver 106 to the conventional program guide tuning 
information (channel frequency, polarization, header ID, 
etc.) needed to acquire the program currently being 
broadcast on ESPN. 

[0044] An additional feature of the video/picture 
segment 228 is an information area that can pop up 
(i.e., a child window) whenever a cursor rolls over a 
given portion of a video/picture area. The information 
area may provide any desired information about the pro- 
gram, for example, the title, program description, pro- 
gram duration, program rating, etc. Such information is 
typically broadcast in conjunction with known guide sys- 
tems to provide users with information regarding a pro- 
gram. 

[0045] The fifth segment is a "link" segment, which 
can be found in various areas on a given screen. Links 
(including graphical interface "buttons" for selecting cer- 
tain features and/or operations) may be provided for the 
active video segment 222 and/or special auxiliary areas 
234 located at the bottom of a given template page. In 
one embodiment of the present invention, links may be 
provided in association with (e.g.. within or adjacent to) 
one or more of the video/picture segments 228. . 
[0046] When the user selects a link an action is 
taken. For example, "web" links may be provided that 
allow the viewer to "pull-up" a related webpage previ- 
ously downloaded from the satellite 104 and cached in 
the PC 128, or that is retrieved via the network connec- 
tion 122 when requested. Alternatively, selecting the 
"web" link could bring up on an available area of the 
template 220 a list of available web pages. When "grid- 
guide" links are selected, a conventional grid-based 
program guide is displayed to the user. When "preview" 
links are selected, the user may select and run previ- 
ously stored or retrieved video clips of the program in its 
video/picture area. When "software" links are selected, 
the user may download related software (e.g., computer 
games, applications software or web originated soft- 
ware). For example, a "computer disk" button/link could 
be used for accessing the data catalogue of webcaster 
broadcasts, downloading software the next time it is 
broadcast, retrieving or purchasing software already 
cached, or for retrieving software over the network con- 
nection 122. "View" links could make a given picture 
area active, "full" links may expand the associated 
video/picture area to occupy a substantial portion of the 
full screen, "record" links may use the broadcast time 
and channel information associated with a program to 
control a video recorder to record the program at its 
broadcast time, "buy" links may allow users to purchase 
pay-per-view programming or services via conventional 
impulse-pay-per-view purchase screens, for example, a 
"dollar sign" button/link could be used to launch an 
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impulse pay-per-view process for pay-per-view pro- 
grams. "Data-catalog" links could take the user to the 
webcaster broadcasting schedule for the system. A 
"lock" link could be used for controlling access to pro- 
grams, for example by limiting movies to no higher than 
a PG-13 rating (ratings information is obtained from the 
grid-guide datastream). A "star" link could be selected 
to bring up a list of the cast in the current show. A "video 
tape" link could be used to launch automatic VCR pro- 
gramming by accessing the channel and time informa- 
tion from the grid-guide datastream and using that 
information to control the recording features of the VCR 
136. A "checkbox" button/link could be used to add to a 
list of favorites stations or to configure a viewing 
agenda. A "question mark" button/link could be used for 
displaying additional information associated with the 
program, such as times, ratings, and a textual synopsis. 
Thus, the various links may be selected and activated 
by the user to launch the PPG between various states 
or pages. Of course, there are many other links and 
associated actions that could be provided. 
[0047] In accordance with the present invention, a 
time line 236 may be provided adjacent to one or more 
of the active video areas 228. The time line 236 may 
indicate the progress of the currently running program 
For example, the ends of the time line 236 may repre- 
sent the respective start and finish times of the currently 
running program and a shaded portion of the time line 
236 may correspond to the time elapsed from the start 
time to the current time. Thus, a user may quickly deter- 
mine how much of a currently running program is avail- 
able for viewing before making a viewing 
selection/purchase. In some embodiments, the user 
may be prevented from buying a pay-per-view program, 
for example, if less than 50% of the program remains to 
be broadcast. 

[0048] In other embodiments, the time line 236 may 
be used to select a viewing time for a video/picture area. 
In these embodiments, scrolling back and forth in time is 
accomplished with arrow links, and jumping to a partic- 
ular time can be performed, for example, via a calendar 
(not shown) that pops up when a calendar link is 
selected. Of course, any time selection metaphor could 
be used. The current time is the default, however, going 
forward in time allows for agenda planning, VCR pro- 
gramming, etc. The video picture in the video area auto- 
matically changes to the pictures appropriate for the 
requested guide time-frame. 

[0049] The current date and time are displayed in a 
date/time segment 238. Moving the display time for all 
of the video/picture areas at once could be accom- 
plished via a calendar or time bar or menu that could be 
accessed by, for example, double-clicking a mouse con- 
trol on the date/time segment 238. 
[0050] FIG. 4 illustrates, by way of example only, the 
"data" category template of one embodiment of the 
present invention. The video/picture segment 228 dis- 
play various data delivery services. For example, a 



NASDAQ service channel displays a stock ticker with 
recent stock symbols and prices, and a sports ticker 
shows scores for games currently being played. The 
data delivered by these services is updated periodically 
5 and scrolls across the various video/picture areas 238. 
Persons of ordinary skill in the art will appreciate that 
text, graphics, video, sound, and software can be com- 
bined in various combinations to deliver content associ- 
ated with data delivery services. For example, breaking 
70 CNN news headlines with video/audio clips could be 
transmitted as file data and stored in a designated 
memory location of the PC 128. Viewer's are notified of 
the general nature of the story and the availability of the 
news clip by a scroll across the live video feed for CNN, 
is or by a pop-up "breaking news" link/button, or some 
other method. The viewer can access the video clip by 
clicking the button/link. Similarly, software (e.g., a game 
or new version of a spreadsheet application) could be 
requested and downloaded. 
20 [0051 ] At the bottom of each template 220 shown in 
FIGS. 2-4 are auxiliary areas 234. These areas can be 
used in a variety of ways, such as for additional tem- 
plates/buttons, advertisements, special messages, and 
other communications. These areas can also be used to 
25 allow various PPG services and/or operations to be 
launched without having to alter the basic template 
presentation. For example, if an impulse pay-per-view 
operation is initiated, the purchase screens from the 
grid-guide datastream could be displayed in the auxil- 
30 iary areas 234 instead of the video area for that channel 
or the full screen, thereby allowing the purchase to pro- 
ceed while still viewing the basic PPG template. Or, if a 
software game associated with the channel is down- 
loaded, it can be launched and run in the auxiliary areas 
35 without having to exit the current PPG template. 

[0052] FIG. 5 shows one example of a box occupy- 
ing the video/picture segment 220 where enlarged live 
video or a web page are displayed in response to the 
selection of the "Full" or "Web" buttons respectively. In 
40 the present embodiment the active video segment 222 
can be replaced with a logo associated with the current 
channel or web page, and the category segment 226 
lists web pages associated with the current category. A 
"category" button/link under the active video/audio seg- 
45 ment 222 allows the user to return the category seg- 
ment 226 to a list of categories, thereby allowing the 
^ user to return the screen to a particular category tem- 
plate. 

50 HI. Receiver Station Generally 

[0053] As noted above, the PPG of the present 
invention is preferably implemented within a DTH PC- 
based satellite communication system 100 such as that 
55 depicted generally in FIG. 1 . Discussed in more detail 
below is a preferred system and method for executing 
the PPG software of the present invention. In particular, 
a preferred receiver station 106 architecture is dis- 
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closed. In addition, preferred data transmission meth- 
ods that facilitate the PPG's ability to receive and 
manage the large amount and variety of digital informa- 
tion that is broadcast within the DTH system 100 are 
disclosed. 

[0054] FIG. 6 is a detailed illustration of a preferred 
implementation of the receiver station 106 shown in 
FIG. 1. As shown, the receiver station 106 includes the 
reception antenna 124, the LNB 126, and the PC 128. 
The PC 128 includes the monitor 130 and the comput- 
ing unit 132, which may have a modem connection via 
the PSTN to the network 122. The computing unit 132 
includes, inter alia, a satellite receiver card 418, a 
video/audio decoder card 420, which may be integrated 
with the receiver card 418, a conditional access card 
422, a mass memory such as a hard disk (not shown), 
and processing/control capabilities such as a PC moth- 
erboard 424. The satellite receiver card 418 includes a 
tuner 426, a demodulator 428, a forward error correc- 
tion (FEC) decoder 430, and a transport functional 
processing block 432. The video/audio decoder card 
420 includes a video/audio decoder 434, an optional 
NTSC and/or ATSC output driver 438, and a VGA output 
driver 436. The satellite receiver card 418 and 
video/audio circuits (e.g., video/audio decoder card 
420) perform the functions of receiving and decoding 
the signal received from the LNB 126. The incoming sig- 
nal is received by a satellite receiver card 418 and 
passed through a series of initial processing operations 
including the tuner 426, the demodulator 428, and the 
forward error correction decoder 430, before passing to 
the actual transport functional processing block 432. 
Although the functional circuits within the transport 
functional processing block 432 are not illustrated, they 
are identical to the channel demultiplexing, decryption, 
and access determination circuit blocks of a standard 
transport decoder. For example, the transport functional 
processing block 432 receives the transport stream or 
bitstream of digitized data packets containing video, 
audio, scheduling information, and other data. The dig- 
ital packet information contains, identifying headers as 
part of its overhead data. Under control of the PC's main 
processor/controller (typically located on the PC moth- 
erboard 424), the transport functional processing block 
432 filters out received data packets that are not cur- 
rently of interest. Received data packets that are of 
interest are routed through decryption and access con- 
trol operations within the conditional access card 422. 
Access control may be provided by any known means. 
For example, access control may be achieved by requir- 
ing a data packet to have a proper authorization code in 
order to be passed to the video/audio decoder card 420 
[0055] The transport functional processing block 
432 passes the data to the video/audio decoder 434 of 
the video/audio decoder card 420. The authorized data 
of interest are stored in system RAM (not shown) for 
buffering, and the video/audio decoder 434 retrieves the 
data from RAM as needed. 



[0056] The allocation of memory and control func- 
tions may be arbitrarily divided between the PC sys- 
tem's function cards (e.g., the satellite receiver card 
418, the video/audio decoder card 420, etc.). Thus, a 

5 substantial amount, or possibly all, of the control and 
memory functions for operation of the present invention 
may be integrated within a single card, or alternatively, 
may be incorporated within the PC motherboard 424. 
When needed, the data is routed to the video/audio 

io decoder 434, which includes display circuitry. For video 
data, the video/audio decoder 434 reads in the com- 
pressed video data from its RAM, parses it, creates 
quantized frequency domain coefficients, then performs 
an inverse quantization, inverse discrete cosine trans- 

7 5 form (DCT) and motion compensation. At this point, an 
image has been reconstructed in the spatial domain. 
This image is then stored in a frame buffer in the video 
decoder's RAM. At a later time, the image is read out of 
the frame buffer and passed through the display cir- 

20 cuitry to the VGA output driver 436 and optionally, to the 
NTSC and/or ATSC output driver 438. The display cir- 
cuitry also generates the graphics that allow text such 
as the PPG electronic program grid guide data to be dis- 
played. 

25 

IV. Receiver Station Architecture 

[0057] Illustrated in FIG. 7 is a system architecture 
block diagram 500 depicting, by way of example only, a 

30 preferred organization of the PC's computing unit hard- 
ware and software which may implement aspects of the 
present invention. A tuner driver 502, a TV control block 
504, a video MPEG driver 506, and a video VGA driver 
508 provide the major functions of a conventional inte- 

35 grated receiver decoder (IRD). The tuner driver 502 
receives a digital signal modulated on an RF carrier 
(e.g.. a digital satellite downlink signal) on line 510, and 
performs known IRD functions to parse out and selec- 
tively control the flow of conditional access, video/audio, 

40 and MPT data streams. The tuner driver 502 passes 
selected video/audio data packets to the video MPEG 
driver 506 on line 512. The MPEG driver 506 controls 
the MPEG decoding hardware, synchronizes video and 
audio data, and manages the buffering of video and 

45 audio data to be displayed. The MPEG driver 506 
passes decoded video information to the video VGA 
driver 508 via line 516. The VGA driver 508 processes 
the decoded video information 514 and provides a dis- 
play signal that may be, for example, a standard RGB 

so output on line 516. The TV control block 504 controls 
the size and location of the video window via an MPEG 
decode control signal on line 518 and a VGA window 
display control signal on line 520 that are passed to the 
• video MPEG driver 506 and the video VGA driver 508 

55 respectively. 

[0058] With respect to file data, the tuner driver 502 
passes file data (e.g., websites, software, etc.) as MPT 
data packets to a tuner NDIS driver 522. The NDIS 
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driver 522 strips the MPT header and passes standard 
IP data packets 524 using Microsoft® NDIS protocol to 
a standard Windows® Winsock® interface 526. File 
data 528 may alternatively be passed to the Winsock® 
interface 526 as IP data packets via a network driver 
530 that exchanges information with a network connec- 
tion 532 that may, for example, be an Ethernet, ISDN, or 
POTS connection. 

[0059] A data manager 534 functions as a data dis- 
tributor or data hub. The data manager 534 receives 
and interprets file data from line 536. The data manager 
534 further provides an optional HTTP proxy service via 
line 538, uses an SDP + data store 540, and schedules 
data-related tuning requirements. The data manager 
534 may store data files (e.g., HTML, GIF, etc.) on a 
local file system 541 (e.g., a hard disk) via a fifth data 
path 542. 

[0060] The data manager 534 may use a TAP I 
library block 546 to communicate via a telephony appli- 
cation programming interface (TAPI) via line 544. The 
TAPI library block 546 is in direct communication with a 
modem 548 having a POTS phone line connection 550. 
In this way, the data manager 534 can report to a serv- 
ice provider which advertisements a particular user has 
viewed or selected (i.e., advertisement tracking). In 
addition, the data manager 534 communicates with a 
service/CA manager 552, which sets tuning priori- 
ties/controls, manages conditional access messages, 
and resolves messages relating to program tuning infor- 
mation that are exchanged via a third data path 554 
to/from the tuner driver block 502. 
[0061] The SDP + data store 540 is a database that 
contains all the current SDP + record information. The 
SDP + data store 540 passes DPG data store queries 
for data item description and display formatting informa- 
tion to a data program guide block 558 on line 556. The 
data program guide block 558 contains the dynamic 
HTML pages, including graphic content, that is currently 
being broadcast by the satellite communication system 
100. The data program guide block 558 may retrieve 
files from the local file system 541 via a fourth data path 
560. The SDP + data store 540 may also pass enriched 
TV data store queries 562 to an enriched TV function 
564 that serves to map a channel to an IP address and 
a port. The enriched TV function 564 may further 
receive tuning control information, via line 566, from a 
tuning control interface 504 and may, accordingly, pass 
screen formatting information to the TV control block 
504 on line 570. The enriched TV function 564 and the 
data program guide block 558 may exchange informa- 
tion with a browser application 572 along a first data 
path 574 and a second data path 576. respectively. 
[0062] As described in section II of this disclosure, a 
user may interact with the PPG to invoke the download 
of file data (e.g., by selecting various "software" links). 
The PPG utilizes SDP+ records to perform this task. 
The SDP + records are stored in the SDP + data store 
540. At the scheduled time of reception, the data man- 



ager 534, which holds schedule information, examines 
the records in the SDP + data store 540 to determine 
the multicast IP address on which the download will be 
broadcast. After the data manager 534 has determined 

5 the multicast IP address, the service manager 552 looks 
to the BARP table, which may be stored on the local file 
system 541 , to determine tuning information for the mul- 
ticast IP address found in the SDP+ record. For exam- 
ple, a broadcast of Quicken 98™ software may be 

w broadcast on multicast IP address 1 .2.3.4 and that mul- 
ticast IP address may correspond to tuning information 
indicating transponder two SCID five, according to the 
BARP table. Once the tuning information is determined, 
it is passed to the service/CA manager 552, which 

is tunes the tuner driver 502 to, for example, transponder 
two. SCID five. 

[0063] File information received by the tuner 502 is 
passed to the tuner NDIS driver 522, where it is con- 
verted into IP data and passed to the Winsock® 526, via 

20 line 524. The Winsock®, in turn, passes the IP data to 
the data manager 534, which performs the BFDP func- 
tion on the IP data to recover the data for Quicken '98™. 
The data associated with Quicken '98™ is stored on the 
local file system 541 for later use. Any data determined 

25 by BFDP to be missing from the received Quicken "98™ 
file will be obtained on subsequent broadcasts of the 
file. When the complete file has been stored on the local 
file system 541 , Quicken '98™ is complete and ready to 
run. 

30 

V. Data Packets 

[0064] FIG. 8 is a diagram illustrating a preferred 
type of transport data packet that may be transmitted via 

35 the system 100 shown in FIG. 1 and processed by the 
receiver station 106 shown in FIGS. 22 and 23. More 
specifically, the data packet may be coupled to the 
receiver station shown in FIG. 7 via line 510. The pre- 
ferred data packet shown in FIG. 8 is in the format and 

40 of the type used in the DirecTV® digital broadcast sys- 
tem. As shown, each data packet may be, for example, 
147 bytes long. The first two bytes (a byte is made up of 
8 bits) of information contain the SCID and flags. As 
previously stated, the SCID (service channel ID) is a 

45 unique 12-bit number that uniquely identifies the 
packet's service channel. The flags are made up of four 
bits used primarily to control whether or not the packet 
is encrypted and, if encrypted, which key to use to 
decrypt the packet. The third byte of information is 

so made up of a four-bit packet type indicator and a four-bit 
continuity counter. The next 127 bytes of information 
consists of the "payload" data, which is the actual usa- 
ble information sent from the program provider. The 
payload can be any of the various types of data sent 

55 over the airlink. including video, audio, conventional pro- 
gram guide data, data related to the layout/format/con- 
tent of the template pages of the present invention, 
conditional access data, webcasting data, software 
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download data, etc. 

VI. Audio/Video Processing 

[0065] The architecture shown in FIG. 7 may be 
used to receive audio and video signals associated with 
television programming. When a user desires to watch 
television programming, the service/CA manager 552 
tunes the tuner driver 502 to the appropriate trans- 
ponder and SCID or SCIDs to receive the appropriate 
programming signals. The received signals are passed 
to the MPEG video driver 506 via line 512. The MPEG 
video driver 506 appropriately processes the received 
signals to obtain audio and video signals that are 
passed to the video VGA driver 508, which, in turn, 
passes the signals to a monitor for display. 

VII. Data Processing 

A. Protocol Stack/Broadcast File Download Protocol 
(BFDP) 

[0066] As discussed in section I of this disclosure, 
the PPG of the present invention requires the presence 
of appropriate data at the receiver station 106. Although 
a variety of data processing techniques could be used in 
conjunction with the PPG of the present invention, 
BFDP, BARP, and SDP + are exemplary of preferred 
data processing methods. Respectively, these methods 
provide a way of reliably transferring file data in a one- 
way communication channel, resolving IP addresses 
into physical addresses, and announcing to the receiver 
station 106 how to display available data streams for 
selection, and when and how to tune to data streams 
selected by the user. 

[0067] Illustrated in FIG. 9, is a preferred data flow 
through a protocol stack that utilizes the BFDP, BARP, 
and SDP + data processing methods. The transmission 
station 102 (or "headend") builds transport data packets 
for transmission in accordance with the headend data 
flow arrow. There are four primary data flow paths 
through the protocol stack at the transmission station 
102. File data begins at an application layer 602 and is 
passed down through a BFDP layer 604, a UDP layer 
608, an IP layer 610, and is encapsulated for transmis- 
sion to the receiver station 106 by an MPT layer 61 4 and 
a transport layer 616. Webcast data begins at the appli- 
cation layer 602 and is passed down through a webcast 
layer 603, the BFDP layer 604, the UDP layer 608, the 
IP layer 610, the MPT layer 614, and the transport layer 
616. SDP+ records begin at the application layer 602 
and are passed down through an SDP + layer 606, the 
UDP layer 608, the IP layer 610. the MPT layer 614 and 
the transport layer 616. BARP information begins at the 
application layer 602 and is passed down through a 
BARP layer 612, the MPT layer 614 and the transport 
layer 616. Transport packets received at the receiver 
station 106 (or "subscriber") are resolved into BARP 



information, SDP + records, webcast information, and 
file data by passing the received packets up through the 
protocol stack in the direction indicated by the sub- 
scriber data f tow arrow. 

5 [0068] Illustrated in FIG. 1 0 is an exemplary method 
of processing a data packet using the protocol stack 
shown in FIG. 9. FIGS. 9 and 10 are described is more 
detail below in connection with in-depth discussions 
regarding the BFDP, BARP, and SDP + data processing 

10 methods. 

[0069] Downloading file data is especially difficult 
within the DTH system 100 (shown in FIG. 1) because 
the DTH system 100 does not provide a backchannel 
communication path from the receiver station 106 to the 

15 transmission station 102 (i.e., the communication path 
is a one-way path to the receiver station 106). The 
absence of a backchannel makes it impossible for the 
receiver station 106 to acknowledge to the transmission 
station 102 that a software file was completely received 

20 and error free. Additionally, the absence of a backchan- 
nel prevents the receiver station 106 from requesting 
rebroadcast of missing data from the transmission sta- 
tion 102. Although the communication channel associ- 
ated with the DTH system 100 has a very low bit error 

25 rate, relatively long periods of signal interruption may 
occur. For example, snow or rain, either at the transmis- 
sion station 102 or the receiver station 106 may cause 
the communication channels of the system 100 to fade, 
thereby causing received signal errors. Additionally. 

30 user activity, such as receiver station tuning or deactiva- 
tion, may cause signal interruptions. If signal interrup- 
tions occur during the download of file data, the file data 
will be incomplete and inoperable. 
[0070] One preferred method of addressing the dif- 

35 f iculty associated with transmitting file data along a one- 
way communication path, such as that used by the PPG 
of the present invention, uses data carousels at the 
transmission station 102 that repeatedly broadcast the 
same file data to the receiver station 106 in conjunction 

40 with a data transfer protocol that is the subject of a co- 
pending, commonly assigned patent application serial 

no. filed on and 

entitled . The Broadcast File 

Download Protocol (BFDP) prepends a header to the 

45 file before transmission of the data packets. This header 
allows a download file to be reassembled from informa- 
tion received during one or more broadcasts of the 
same download file. Thus, if some file data is lost or cor- 
rupted during a first broadcast of the download file, 

so BFDP allows the receiver station 106 to "fill in" any 
missing or corrupted file data with file data received dur- 
ing a subsequent broadcast of the same download file, 
thereby avoiding the constraint of having to receive an 
entire file without corruption/interruption during a single 

55 broadcast. 

[0071] The details of BFDP will now be explained 
with reference to FIGS. 9 and 10. If a file (e.g., a web- 
site, a software file, etc.) is to be broadcast from the 
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transmission station 102 to the receiver station 106, 
data from the application layer 602, such as webcast, is 
passed to the BFDP layer 604. For purposes of expla- 
nation of the BFDP, it will be assumed that a data file 
620 having 2 kilobytes (2K) of data is to be transmitted. 5 
The data file 620 is received by the BFDP layer 604, 
which if necessary, breaks the data file 620 into smaller 
data fragments 622 and 624. For purposes of explana- 
tion it is assumed that the data file 620 is split into two 
1 K data fragments 622, 624 and that a BFDP header 10 
626 is prepended to each of the data fragments 622, 
624. The size of the fragments is a tradeoff between 
overhead and the probability of data loss. If low over- 
head is desired, the size of the data packet will be large 
with respect to the BFDP header on the data. However, 15 
if the probability of data loss is high, the size of the data 
packets should be made small to minimize the data lost 
if a single packet is lost. Typically, the probability of data 
loss is determined by channel characteristics. The 
remainder of the processing for each fragment is identi- 20 
cat A sample format for the BFDP header 626 is shown 
in FIG. 11. 

[0072] The eight fields of the sample BFDP header 
626 provide information concerning the number and 
order of the data fragments 622, 624 that are broadcast 25 
to make up the data file 620. Each field in the sample 
BFDP header 626 is represented by four bytes, except 
for filename, which is represented by sixty-four bytes. 
The Sync, field contains information that may be used to 
assist in identifying the header. An I D field is a represen- 30 
tation of the object ID for the file being broadcast. The 
object ID may be used for data filtering at the receiver 
station 106. The Version field indicates the version of 
the BFDP used to create the present packet. Filename 
is sixty-four bytes of information used to indicate the 35 
filename and path where the data fragment is to be 
stored on the receiver station 106 (e.g., C:\down- 
loads\xyz). Preferably, the filename field is used only for 
special files and is not generally used. For example, 
when webcast information is transferred, a HTTP 40 
header is used and the filename field is ignored. The 
Modified field denotes the last time the fragment was 
modified. Preferably, this representation is in UNIX 
time_t format. Count, Number, and Size fields refer to 
the number of fragments used to make up the original 45 
file data that is broadcast, the number of this fragment, 
and the size of this fragment, respectively. The count, 
number, and size fields are key pieces of information 
that allow BFDP to reconstruct a complete data file from 
multiple broadcasts of the data file. For example, a data so 
file may be broken into 10 fragments and, during trans- 
mission, fragments 1-5 and 8-10 were received by the 
receiver station 106. On subsequent broadcasts of the 
data file, the receiver station 106 examines all of the 
BFDP headers on the received fragments and only 55 
stores the data packets indicated as fragments 6 and 7 
in their BFDP headers, thereby filling in the received 
data file. 



[0073] As shown in FIGS. 9 and 10, after the 
processing is complete at the BFDP layer 604, the 
resulting data packet is transferred to a UDP layer 608, 
which prepends a UDP header 628 to the packet. The 
UDP header 628, which is standard and well known in 
the art, is shown in FIG. 12. The UPD header 628 
includes fields that denote source and destination ports 
for the data. That is, UDP header fields contain informa- 
tion indicating the application that is providing the data 
(source port) and the application that is to receive the 
data (destination port). At this point in the processing, 
the data packet is referred to as a UDP packet 630. 
[0074] Data transferred to a computer through a 
connection is typically in an Internet protocol (IP) for- 
mat, which is well known to those skilled in the art. 
Accordingly, the UDP packet 630 is passed to the IP 
layer 610, which in a well known manner, prepends an 
IP header 632 onto the UDP packet 630, thereby creat- 
ing an IP packet 634. The IP header 632, which is 
shown in FIG. 13 denotes, inter alia, the IP addresses of 
the data source and destination computers. Information 
that is broadcast to a number of users preferably uses a 
multicast IP address. Alternatively, information may be 
addressed to specific users via a standard IP address 
[0075] After the UDP packet 630 has been properly 
processed by the IP layer 610 to create the IP packet 
634, the IP packet 634 is passed to an MPT layer 614. 
The MPT layer 614 processes the IP packet 634 to cre- 
ate an appropriate number of MPT packets 636. For 
example, in digital video broadcasts (DVB) the size of 
the MPT packets may be 185 bytes. Alternatively, the 
MPT packets may be 127 bytes long for other direct to 
home (DTH) applications. For use in the present system 
20, each the MPT packets 636 is 127 bytes long includ- 
ing a header and data. The MPT layer uses a number of 
packet configurations, shown in FIGS. 14A - 14D, to cre- 
ate the 127 byte packets. If the IP packet 634 contains 
1 14 bytes or less, only one MPT packet referred to as an 
"Only Packet" 760 needs to be created. The preferred 
format of the Only MPT packet 760 is shown in FIG. 
14D. The Only packet 760 includes: a six bit flag field 
that is preferably reserved and set to all zeros, a one bit 
start of frame (SOF) field that indicates that this packet 
is the start of the frame, a one bit end of frame (EOF) 
field that indicates that this packet is the end of the 
frame. If the IP packet 634 contains 1 14 bytes or less, 
only one MPT packet 636 will be sent, therefore the 
Only packet header indicates that the Only packet 760 
is the start of the frame and the end of the frame. The 
Only packet 760 may also include a field indicating the 
sub-SCID address of the packet, which preferably 
includes a two byte type code and a four byte type- 
dependent code. Preferably, the type code is 0x0100, 
which signifies that the last four bytes are the multicast 
group address to which this frame belongs. The Only 
packet 760 may also include a frame type field, which 
identifies the type of content in the MPT frame. Prefera- 
bly, this field is used to indicate whether the frame is an 
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IP frame or a BARP frame. Preferably, the frame type 
field is filled using Internet Assigned Number Authority 
(I AN A) standard numbers. Further, the Only packet 760 
may include a cyclic redundancy check (CRC), which is 
a 32 -bit number computed over the entire MPT frame. 
[0076] If the IP packet 634 is to be processed by the 
MPT layer 614 is longer than 114 bytes, Start 730, Mid- 
dle 740, and End 750 MPT packets shown in FIGS. 14A 
- 14D are preferably used to process the IP packet 634. 
The headers of these packets use all combinations of 
the fields described in conjunction with the Only packet 
760. As shown in FIG. 10, the first 118 bytes of the IP 
packet 634 are loaded into the MPT Start packet 730. 
The start header of the MPT packet denotes a MPT 
packet as the start of the frame by setting the SOF bit. If 
the IP packet 634 is larger than 244 bytes the appropri- 
ate number of Middle packets 740 will be filled with 126 
byte sections of data from the IP packet 634. The SOF 
and EOF bits will not be set because the MPT packet is 
a middle packet. Numerous middle packets will be filled 
with the IP data until there is less than 122 bytes of data 
remaining in the IP packet 634. At this point an End 
packet 750, is filled with the last bytes of information and 
appended with a CRC. This method of using Only, Start, 
Middle, and End packets yields MPT packets that are all 
exactly 127 bytes long. 

[0077] After each IP packet 634 has been con- 
verted to one of the MPT packets 636, each of the MPT 
packets 636 is passed to the transport layer 616. The 
transport layer 61 6 places each 127 byte packet into the 
127 byte payload section of a transport data packet 
(shown in FIG. 8). The complete transport data packet 
is passed to the uplink frequency converter 1 1 8 of FIG. 
1 and broadcast to the receiver station 106. 
[0078] As the receiver station 1 06, which is tuned to 
a particular transponder and SCID, receives packets of 
information, the data packets traverse up through the 
protocol stack as indicated by the subscriber data flow 
indicated on FIG. 9. The transport layer removes the 
payload from each transport packet. After the appropri- 
ate processing, the payload is passed to the MPT layer 
614, which strips the MPT header from the packet and 
assembles all relevant data from MPT packets to 
assemble the IP data frame. The IP layer 610 strips the 
IP header 632 from the data, performs well-known IP 
processing functions, and routes the data to the UDP 
layer 608. The UDP layer 608 strips off the UDP header 
628 and routes the remaining information to the proper 
application (port) as denoted by the UDP header. The 
BFDP layer 604 strips the BFDP header 626 from the 
data packets and, using the information in the headers, 
reassembles the data contained in the BFDP packets 
into the data file 620 as sent by the transmission station 
102. Additionally, if necessary, the receiver station 106 
denotes missing data packets through examination of 
the BFDP headers. Thus, the PPG of the present inven- 
tion may reassemble the original data file in accordance 
with the BFDP header fields at the receiver station 106 



after multiple broadcasts of the original data file. That is. 
any missing data after the data is broadcast will be 
"filled in" with the appropriate data from subsequent 
broadcasts of the original data a file. For example, if a 1 

5 megabyte (M B) f ile is broadcast and the receiver station 
106 successfully acquires all but 1 kilobyte (KB) of the 
broadcast information, instead of having to reacquire all 
of the data that the receiver station 106 has already 
received, the receiver station 106 simply waits for and 

10 acquires the 1 KB of data that it needs to complete the 1 
MB file. 

B. Broadcast Address Resolution Protocol (BARP) 

is [0079] As referenced earlier, the broadcast address 
resolution protocol (BARP) layer 612 is required to 
resolve IP addresses into physical (i.e., satellite trans- 
port) addresses. BARP is the subject of a co-pending 
commonly assigned application entitled 

20 , filed on and bear- 
ing serial no. I . The BARP layer 

is coupled to the MPT layer 614 and is used to map a 
multicast source IP address to transport-specific tuning 
information. That is, BARP is a map that tells a receiver 

25 station 1 06 on which transponder or transponders and 
SCID or SCIDs. information from a particular source IP 
address may be found. For example, when a user 
selects information from the PPG, the receiver station 
106 uses BARP to determine tuning parameters (e.g.. 

30 transponder and SCID) for the information selected by 
the user. Preferably. BARP information is periodically 
sent on as many transponders as possible so that users 
have easy access to the most current BARP informa- 
tion. 

35 [0080] BARP consists of a header followed by zero 
or more address records. BARP preferably uses MPT 
frame type 0x0806. FIGS. 15A and 15B represent the 
format of a BARP header and a BARP address record, 
respectively. The BARP header includes version, 

40 change number, record count and reserved fields. In 
this example, version is a 1 byte field that represents the 
version of the BARP format used to create the header 
and address record. Change number is a 1 byte field 
that is incremented each time anything in the header or 

45 any of the address records change. Record count is a 2 
byte field that indicates the number of address records 
that follow this BARP header. The reserved field is a 
four byte field that may be used to provide system flexi- 
bility in the future. 

so [0081 ] The BARP address record, as shown in FIG. 
15B, includes six fields. An IP address field contains a 
four byte representation of an IP address. Transponder 
is a bitmap field identifying the transponders on which 
the previously-noted IP address can be found. Each bit 

55 in the transponder field corresponds to a transponder. 
Set bits in the transponder field indicate the presence of 
the IP address on that transponder. For example, if the 
first bit is set (1 ) and the rest of the bits are clear (0) then 
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the IP address listed in the IP address field is present 
only on the first transponder of the system. The SCID 
field denotes the 12 bit SCID that contains the informa- 
tion provided by the IP address listed in the first field of 
the header. Preferably, the four most significant bits are 5 
reserved. Channel is 10-bit channel number that is 
associated with the this SCID and transponder. For 
example, transponder two, SCID nine may correspond 
to channel 105. Preferably, the most significant 6 bits of 
the channel field are reserved for future use. Service 10 
type is the type and paradigm of the channel associated 
with the transponder and SCID in the address record. 
The reserved field is 3 bytes long and is preferably 
reserved for future system use. Information for channel 
and service type fields are preferably supplied by the J5 
broadcaster to satisfy tuning requirements of subscriber 
units. 

[0082] While the BARP and BFDP protocol layers 
represent one preferred way of transmitting the informa- 
tion related to the PPG of the present invention, other 20 
transmission systems and methods may be substituted 
without departing from the spirit of the invention. 

C. SDP+ Records 

25 

[0083] Another difficulty faced in utilizing the wide 
variety and large amount of information transmitted 
within the DTH system 100 is providing a way for the 
PPG to efficiently find and process the various kinds of 
data that are available at various times within the multi- 30 
program data stream. One preferred method that allows 
the PPG of the present invention to efficiently find and 
process information for presentation to a user are "ses- 
sion description protocol plus" (SDP+) records. SDP+ 
records are the subject of a co-pending commonly 35 

assigned application entitled 

filed on and bearing serial no. 

/ . 

[0084] An SDP + record is an announcement mech- 
anism that includes a number of fields, which are 40 
assembled into a single record or file to provide informa- 
tion on available services such as webcasts, down- 
loads, and streaming data or other services. The SDP + 
protocol is a combination of standard SDP fields and 
augmentations, or extensions, to the standard SDP pro- 45 
tocol. Additional details regarding the standard SDP 
protocol may be found in RFC 2327. The standard fields 
of the SDP protocol that are used in the of the SDP + 
protocol include, protocol version, the owner/creator 
and session identifier (i.e., the IP address of the creator 50 
of the SDP record), the name of the SDP session (i.e., 
the name of the SDP record), a brief description of the 
session (i.e., what the SDP record is for), the multicast 
address on which the session is being broadcast, the 
start and end times of the broadcast, the repeat times of 55 
the broadcast, a list of Internet webpages that can pro- 
vide additional information on the item that is going to 
be broadcast, what the port of the broadcast is (i.e., the 



UDP port of the broadcast), the type of broadcast (e.g., 
BFDP, Stream. Webcast or Intercast), sorting and filter- 
ing information. 

[0085] As noted, an SDP + record may also contain 
information such as the time a particular service will be 
broadcast, the multicast IP address on which the serv- 
ice will be broadcast, the size of the file that wilt be 
broadcast, and information relevant to the PPG such as 
text or images that should be displayed to the user. 
Each download service (e.g., each webcast, each soft- 
ware download, etc.) has its own SDP+ record, which is 
broadcast to all subscribers to inform them of the infor- 
mation that is available for download. With reference to 
PPG information, SDP + records are used by the PC 
1 28 to build particular sections of pages using selected 
information resident within the PC 128 (e.g.. the basic 
page templates shown in FIGS. 2-5) and selected 
dynamic data that is received from a satellite in the form 
of SDP + records. When the user launches the interface 
into another state or page, the PPG builds the destina- 
tion page as instructed by the templates and by the SDP 
+ records. The page is then displayed on the user's PC 
monitor 1 30. 

[0086] SDP + records also allow users to pre-select 
download content from descriptions of the content, then 
filter for that information as it arrives in the one-way data 
stream of the DTH system 100. The descriptions of the 
content may include extended SDP records including 
protocol version, name, times of broadcast, IP address, 
mandatory download status, ID number, run command, 
category, file size, text messages, channel, images, 
keywords, etc. 

[0087] As previously mentioned, SDP + records 
also provide announcement information including con- 
tent type, start time, duration, Internet address informa- 
tion, and actions to be taken on receipt of the 
information. Announcement management is critical to 
finding the data stream, discrete download or webcast 
information in the received transmission. SDP + records 
can be rescinded and modified, once they are present 
on the user s PC 128. SDP+ records can be used to 
indicate mandatory download events such as software 
updates. The system user (client) uses SDP + records 
to schedule program reception. After the client makes 
selections based on the SDP + record information, the 
receiver station 106 properly tunes itself to receive the 
selected information. 

[0088] SDP + records are a combination of conven- 
tional SDP records and extensions to the conventional 
SDP records. Generally, the extensions to the standard 
SDP protocol consist of fields for linking different down- 
load services together, specifying if a download file is 
mandatory, archived or should be run upon download to 
the receiver station 106. The extensions also provide for 
specification and placement of graphics for the PPG. 
the notification of the user upon receipt of the SDP + 
record, and the recission of previously sent SDP + 
records. These unique extensions coupled with the 
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standard SDP protocol yield the SDP + protocol used in 
conjunction with the PPG of the present invention. The 
details of the conventional SDP fields and the unique 
extensions of the present invention are best described 
in conjunction with the exemplary SDP+ records shown 
in FIGS. 16A-16D. 

[0089] Referring now to FIGS. 16A-16D, fields indi- 
cating version (v), record ID (o), multicast IP address 
(c), time (t), and port (m) are required for all SDP+ 
records of any kind. Additionally, for any BFDP down- 
load the object ID BFDP code (a=key:) is needed. The 
run command (a = run:) is required for all streaming 
data downloads. For all streams having an entry in the 
MPG a channel link (a = channel) is required. Addition* 
ally, for all webcasts a URI address field (u = <uri>) is 
required. 

[0090] FIG. 16A is a sample SDP + record for 
streaming data, which is commonly referred to as a 
ticker. The field M v = 0" refers to the version of the SDP 
+ protocol used to produce this SDP + recprd. The 
record ID, which is represented by M o," indicates the 
unique session ID for this particular record. Specifically, 
the session ID for this SDP+ record is 0001 and the ver- 
sion of this record is 1 7. The session ID is a way to refer 
to this particular SDP + record and 17 indicates that 
there have been 16 previous versions of this SDP + 
record before this version. The name of this session is 
represented by "s= Announcement Dump." However, it 
should be noted that the session name is arbitrary 
ASCII text that is used to identify the SDP + record. The 
field "c" represents the multicast IP address of this ses- 
sion and 71" indicates that the Time To Live (TTL) 
value, which indicates the number of "hops" that a 
packet may make before it expires. Multicast IP 
addresses denote the IP address on which the informa- 
tion corresponding to the SDP + record will be broad- 
cast. The multicast IP address is used in conjunction 
with the previously described BARP table to tune a sub- 
scriber's receiver station 106 to the appropriate trans- 
ponder and SCID to receive the broadcast information. 
When a user makes a request to receive broadcast 
information using the PPG, the receiver station 106 
determines the multicast IP address on which the infor- 
mation will be broadcast by looking to the SDP + record 
corresponding to the selection. Once the multicast IP 
address is determined, the receiver station 106 uses the 
BARP table to correlate the multicast IP address to a 
transponder and SCID. The receiver then appropriately 
tunes itself to the proper transponder and SCID to 
receive the broadcast information. Since streaming data 
or tickers are always running, the start and end times 
represented by "t = 0 0" indicate that the data service is 
constantly running and is permanent. The field "m =" 
indicates that the UDP port of the data is 3278 and the 
type of data is streaming data. 

[0091] The SDP+ record shown in FIG. 16A 
includes "a=key:1 ," which indicates that the object ID for 
this SDP + record is 1. The object ID may be used for 



sorting or other functions. The object ID in the SDP + 
record matches the object ID sent in the BFDP header. 
The field "a = run: consoleticker" indicates that when the 
download is complete, an executable file named conso- 

5 leticker should be started. The standard SDP field "a = 
keywds" is used to correlate SDP records to one 
another. For example, in the SDP + record shown in 
FIG. 16A "tsetup" is used to correlate this SDP + record 
with another SDP + record, such as a client download 

w file. 

[0092] FIG. 16B is an example SDP+ record for a 
file download. Similar to the ticker SDP+ record of FIG. 
16A. the file download SDP+ record a file download 
specifies the version of the SDP + protocol used to pro- 

15 duce the SDP + record, the record ID, the name of the 
session, the multicast IP address of the session, and 
the object ID of the session. Additionally, the SDP+ 
record shown in FIG. 16B specifies download times 
using a "t= 3079382400 3155745600," wherein the first 

20 number is the start time of the broadcast and the sec- 
ond number is the end time of the broadcast. The start 
and end times are specified in decimal network time 
protocol (NTP) format. The "r = 10m 10m 0" specifies 
the broadcast repetition of the broadcasts, wherein the 

25 first number indicates the interval between broadcasts, 
the second number indicates the duration of the broad- 
casts and the third number indicates the time offset 
between the broadcasts. The field "m = " indicates that 
the UDP port of the data is 3335 and the type of data is 

30 BFDP data. The SDP+ record shown in FIG. 16B further 
specifies the size of the file that is to be downloaded 
using the "a =fsz" command. The example file download 
SDP+ record specifies a file size of 980K. The file down- 
load SDP + record also specifies that this file is a man- 

35 datory download using the command "a = mandatory." 
That is. the receiver station must receive the data 
broadcast corresponding to this SDP + record during 
one of the broadcast times. The field "a = run:catalogin- 
stall.exe" specifies that after the data associated with 

40 the SDP + record is received, the file cataloginstall.exe 
must be executed. 

[0093] FIG. 16C is an example of an SDP+ record 
that is used to specify information pertinent to a web- 
cast. In addition to using the fields previously described 

45 in conjunction with the file download and ticker SDP + 
records, the webcast SDP + record may use the session 
description field denoted as "i = ." This field is an ASCII 
text field that may be used to describe the content of a 
particular session or webpage. The session description 

so field may be used as the program preview description 
represented as horizontal lines in a child window (not 
shown) that may pop-up when the system pointer rolls 
over a video image representing a program. Alterna- 
tively, the session description field of the SDP + record 

55 may be used in conjunction with SDP + records other 
than webcast SDP + records. The webcast SDP + 
record also includes a field denoting the URI of the web- 
page that is broadcast. The webcast SDP + record also 
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uses the standard SDP extension "a = cat," which is 
used for sorting and filtering the SDP + records. 
[0094] The webcast SDP + record uses the unique 
extension "a = displayrtype =" to indicate how the infor- 
mation content from the webcast will be displayed to the 5 
user. Additionally, the unique SDP+ field "a = img" is 
used to associate an image file (in this case cnn.gif) with 
a webcast. This image may be used as a thumbnail or 
any other representation of the content of the webcast. 
The image field and the display type field can work io 
together to provide information for the PPG. Display 
type may be used to indicate on which page of the PPG 
the image specified in the image field must be placed. 
For example, type may be used to specify Movies, 
Sports, New, Data, or any other available category, is 
each of which may be represented by a number. As 
shown in FIG 16C, type = 1 is specified, which may cor- 
respond to Movies. Accordingly the image cnn.gif will be 
placed on an appropriate page of the PPG as shown in 
FIG. 2. The specification of priority =8 denotes the par- 20 
ticular location in which the cnn.gif image will be placed 
on the page. Referring to the movies page shown in 
FIG. 2, different priorities correspond to different loca- 
tions in the arrangement of the images within the 
video/picture segment. 25 
[0095] FIG. 16D is an example of an SDP + record 
that may be used to represent enriched TV. In addition 
to the field discussed in conjunction with the SDP + 
records, this SDP + record includes the field "a = chan- 
nel." This field contains a 32-bit channel number that 30 
associates the data contained in the enriched video to 
channel content of a channel located in the program 
guide. The information contained in the enriched TV 
may be associated through a number of program guide 
channels. 35 

D. Webcast 

[0096] As previously noted, the DTH system 100 
broadcasts discrete downloads. These downloads are 40 
data items that have well-defined broadcast schedules 
and require detailed announcement information to 
locate the items in the received data. Examples of dis- 
crete downloads include software applications, such as 
spreadsheets, word processors or games. Webcasting 45 
is a special case of the discrete download. A webcast is 
an ongoing and repeating download of specially 
selected web content. The content is usually grouped 
by domain. Minimal scheduling is required for down- 
loading webcast information. Multiple groups of content so 
may be identified by the same identifier, thereby creat- 
ing a one-to-many relationship among the items of inter- 
est. The system 100 may archive webpages pages on a 
the PC 128 for later viewing. 

[0097] As webpage information is received by the 55 
subscriber unit it is stored for later use. In the preferred 
embodiment, webpage information is received in a com- 
pressed format and is stored directly (i.e., without 



extraction) by the subscriber unit. Preferably, the 
present invention uses an archiving scheme based on 
the PKWare™ PKZIP™ format. However, other alterna- 
tive archiving formats may be used. If the archived files 
are compressed, the files are preferably extracted on 
demand using a PKWare™ extractor. If, however, the 
files are not compressed, any ZIP extractor may be 
used to extract and view the files. Preferably, the filena- 
mes used in the webcast archive are actually the uni- 
form resource identifier (URI). 

[0098] Preferably, webcast archive files have a ded- 
icated filename extension. On any given data carousel, 
the contents of which is repeatedly broadcast, there 
must be exactly one main file for each webcast. Prefer- 
ably, this file contains a snapshot of the entire website or 
website subset as selected for broadcast. Update 
archive files may be used to replace portions of the 
main file on the carousel. The subscriber unit stores ail 
archive files in a subdirectory corresponding to the ses- 
sion ID of the webcast. Preferably, when a main file is 
received that is newer than the current main file in that 
directory, all other files in that directory will be removed 
and any links in the proxy server's cache map file for this 
webcast will be replaced with the URIs in the new main 
file. 

[0099] In accordance with the present invention, the 
subscriber unit preferably maps uniform resource loca- 
tors (URIs) to archive files. The map allows the sub- 
scriber unit to locate the archive file containing a URI 
that the user desires to view. When the subscriber unit 
receives the main file, the subscriber unit removes all 
files and cache map file links to the associated session 
prior to the receipt of the new main file. When the user 
requests a webpage, the subscriber unit extracts and 
decompresses the appropriate archive file data to a 
socket. This extraction is done in real time rather than 
extracting the entire archive file to disk. The subscriber 
unit also preferably has the capability to save partially 
downloaded files and acquire missing portions of the 
files on the next broadcast of the files as with all BFDP 
deliveries. 

[01 00] In accordance with the present invention, the 
headend unit is capable of manipulating the archived 
files using functions that archive files, determine the 
number of files in an archive file, return the name of a 
particular entry in an archive file, remove entries from 
an archive file, and merge a number of archive files into 
one archive file. The function that puts entries into an 
archive file includes a field denoting the file or files to be 
archived. Preferably, wildcard indicators may be used to 
specify a number of filenames for entry into the archive 
file. The archive function also preferably allows for a 
specification of a location to which the archive file 
should be written (e.g.. a path name). In a preferred 
embodiment the archive function allows for specification 
of compression or no compression for the archived file. 
The archive function parses the specified files, reads 
the hypertext transport protocol (HTTP) header, and 
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archives the specified files to an output file using the 
URI found in the HTTP header. 
[0101] A function that counts the number of files in 
an archive is also preferably implemented at the head- 
end unit. This function allows for a specification of an 
archive filename and returns the number of files stored 
in the archive file. Another desirable function is that of a 
function that returns the name of a file located in an 
archive file. This function allows for specification of an 
archive filename, the index or location of the file in ques- 
tion, the name of a buffer that will be filled with the name 
of the file in question, and the size of the specified 
buffer. Based on the inputs specified this function pref- 
erably returns the name of the file located in the speci- 
fied index position in the specified archive file, the size 
of the file, and the length of the character string returned 
in the buffer size. 

[01 02] A function that erases portions of an archive 
file is also desirable. This erasing function allows for the 
specification of the archive file in question, the array 
index or indices to be erased from the archive file, and 
the number of elements specified in the index or indices 
to be erased. Preferably, a function is included that 
allows for the merging of two archive files. This merging 
function allows for the specification of two archive file 
names. One of the archive filenames is the file that is to 
be merged into the archive file bearing the other speci- 
fied filename. 

VIII. Conclusion 

[0103] Of course, it should be understood that a 
range of changes and modifications can be made to the 
preferred embodiment described above. It is therefore 
intended that the foregoing detailed description be 
regarded as illustrative rather than limiting and that it be 
understood that it is the following claims, including all 
equivalents, which are intended to define the scope of 
this invention. 

Claims 

1 . A computer based graphical user interface for facil- 
itating the selection and display of transmitted 
audio, video, and data, comprising: 

an active video segment adapted to display a 
currently tuned program; 
a category segment listing various categories 
of programs or services available for viewing; 
a video/picture segment having a plurality of 
video/picture areas associated with the cate- 
gory segment, wherein selection of a one 
video/picture area invokes the interface to com- 
mand a receiver to tune to a particular program 
or service associated with the one video/pic- 
ture area and to display the particular program 
in the active video segment; and 



a graphic/link segment, wherein selection of a 
graphic/link invokes a function associated with 
the graphic/link. 

5 2. The interface of claim 1, wherein the graphic/link 
segment includes a web graphic/link indicating that 
there is a. web page related to at least one 
video/picture area from the plurality of video/picture 
areas. 

10 

3. The interface of claim 1, wherein the graphic/link 
segment includes grid-guide links that invoke the 
interface to display a program grid-guide. 

75 4. The interface of claim 1, wherein the graphic/link 
segment includes video-clip links that invoke the 
display of video clips in the video/picture segment. 

5. The interface of claim 1, wherein the graphic/link 
20 segment includes software links that invoke the 

download of software to the receiver. 

6. The interface of claim 1, wherein the graphic/link 
segment includes software links that invoke the dis- 

25 play of a data catalog that provides a schedule of 
when particular computer programs/web pages will 
be broadcast and available for download to the 
receiver. 

30 7. The interface of claim 1, wherein the graphic/link 
segment includes links that invoke the purchase 
and display of a pay-per-view program. 

8. The interface of claim 1 , further comprising, a page 
35 segment, whereby a user may select from one or 

more pages associated with a particular category. 

9. The interface of claim 1, further comprising a time 
line associated with one or more of the video/pic- 

40 ture areas. 

10. The interface of claim 1, wherein the categories 
within the category segment listing include at least 
one from the group of categories consisting of rnov- 

45 ies, sports, news, kids & family, shopping, music, 
educational, entertainment, and favorites. 

11. The interface of claim 1, wherein the video/picture 
segment has six 3:4 aspect ratio video picture 

so areas. 

12. The interface of claim 1, further including one or 
more auxiliary display areas. 

55 13. A method for facilitating the selection and display of 
transmitted audio, video, and data, comprising: 

displaying in a category segment a listing of the 
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various categories of programs available for 
viewing; 

displaying in an active video segment a 
video/service channel to which a receiver is 
currently tuned; 

displaying a graphic/link segment containing a 
least one graphic/link that invokes a feature or 
service associated with the graphic/link; 
displaying a video/picture segment having a 
plurality of video/picture areas associated with 
the category segment; 

receiving an input from a user, the input being 
a selection of a one video/picture area selected 
from the plurality of video/picture areas; 
commanding a receiver to tune to a particular 
program or service associated with the one 
video/picture area; and 

displaying the particular broadcast program in 
the active video segment. 

14. The interface of claim 13, wherein the graphic/link 
segment includes a web graphic/link indicating that 
there is a web page related to at least a one from 
the plurality of video/picture areas. 

15. The interface of claim 13. wherein the graphic/link 
segment includes grid-guide links that invoke the 
interface to display a program grid-guide. 



within the category segment listing include at least 
one from the group of categories consisting of mov- 
ies, sports, news, kids & family, shopping, music, 
educational, entertainment, and favorites. 

5 

23. The interface of claim 13. wherein the video/picture 
segment has six 3:4 aspect ratio video picture 
areas. 

10 24. The interface of claim 13, further including the step 
of displaying one or more auxiliary display areas. 
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16. The interface of claim 13, wherein the graphic/link 30 
segment includes video-clip links that invoke the 
display of video clips in the video/picture segment. 

17. The interface of claim 13, wherein the graphic/link 
segment includes software links that invoke the 35 
download of related software to the receiver. 



18. The interface of claim 13, wherein the graphic/link 
segment includes software links that invoke the dis- 
play of a data catalog that provides a schedule of 40 
when particular computer programs/web pages will 
be broadcast and available for download to the 
receiver. 



19. The interface of claim 13, wherein the graphic/link 45 
segment includes links that invoke the purchase 

and display of a pay-per-view program. * ..\ : 



20. The display of claim 13, further including the step of 
displaying a page segment, whereby a user may so 
select from one or more pages associated with a 
particular category. 



21. The display of claim 13. further including the step of 
displaying a time line associated with one or more 55 
of the video/picture areas. 



22. The interface of claim 13, wherein the categories 
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UDP Header 628 
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IP Packet Header (Version 4) 632 
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Example Ticker SDP+ Record 
v=0 

o=DTV 0001 17 DSS IP4 
s= Announcement Dump 
c=DSS IP4 233.17.43.6/1 
H)0 

m=data 3287 UDP STREAM 
a=key:l 

a=run:consoleticker 
a=keywds:tsetup 

FIG.16A 



Example File Download SDP+ Record 
v=0 

o==DTV 0008 17 DSS IP4 

s=Data Catalog 

c=DSS DM 233.17.43.3/1 

t=3079382400 3155745600 

r=10m 10m 0 

m=data 3335 UDP BFDP 

a=key:8 

a=fsr980000 

a=mandatory 

a=run:cataloginstall.exe 

FIG.16B 
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Example Webcast SDP+ Record 
v=0 

o=DTV 900 17DSSIP4 
s=CNN 

i=Research financial markets worldwide, get stack quotes, and calculate your 

mortgage payments * all on-line. Read the "hot stories" of the week in the financial 

world. Complete listing of CNN's Financial Network television broadcasts. 

u=httpV/www.cnn.com/index.htm 

c=DSSIP4 233.17.43.7/1 

t=00 

m=data 3334 UDP WEBCAST 

a=cat:News 

a«key:900 

a=fez: 16000000 

a=displayrtype=l t priority=8 

a=img:cnn.gif 

FIG.16C 

Example data enriched video SDP+ record 
v=0 

o=DTV 0201 17 DSS IP4 
s=CNBC 

c=DSS IP4 233.26.24.24/1 
t=00 

m=data 6500 UDP INTERCAST 

a=key:201 

a=channel:775 

FIG.16D 
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